Fixed #425: Show the correct reference type for structured bindings. #451
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This patch changes the behavior of how the resulting reference type of a
binding is determined. Now, the code uses the holding variables
type information of a
BindingDecl
. This seems to be consistent withwhat Clang does.
The reference kind of a binding is determined by the declaration of the
structured binding.
In [dcl.struct.bind] the standard says that the reference type for a
binding is an lvalue reference if the initializer is an lvalue and
otherwise a rvalue reference. The initializer here donates to the hidden
object, referenced as e. WE declare this implicitly by declaring the
structured binding.
We get an rvalue reference in case we declare the structured binding as
a non-reference like this:
We get an lvalue reference if the structured binding is declared as
this:
In the rvalue case we could profit from move because the contents of the
implicitly created object can be moved out.
If we have a reference to the original object moving wouldn't be a good
ting to do, hence an lvalue reference.
std::get
has overloads for both l- and rvalues and returns therespective reference type for each overload.
This behavior is observable thanks to #381 which shows the implicit cast
of the hidden object to a rvalue.